Look up a term called "Escape Analysis". It's not too hard for the VM to do this sort of thing automatically, and it would probably do a better job than a human programmer.
Explicit annotation would help with virtual methods. Since classes can be dynamically loaded, the JIT can never say that "parameter X of virtual method M never escapes the stack." You can improve performance with optimistic approximations, but you're going to have to undo a lot of work if one "bad" method override gets loaded. The problem could be mitigated by good heuristics. I believe that they already do some "unvirtualization" of method calls, which would also help.
I suppose it could be a bad thing to allow "no-escape" annotations on virtual method parameters -- the performance benefit may not be worth the added difficulty -- but I can think of one real-world example where they'd help: java.awt.Component's setSize(...) method. Then again, maybe we just need to make more things immutable.
The object pooling is neat, but it's still too inconvenient for normal use. It's not too inconvenient for people who need the performance, though. It's also not too inconvenient for those who think they need the performance and are already doing some sort of custom object pooling. I wont be using it though.
We need language-level support for more efficient memory use. We need to be able to more precisely declare how we're going to use an object and let the VM handle the optimizations automatically. The FAQ suggests that the 'new' allocator should be overridable but even that is at too low a level. I want to be able to declare parameters with the "no-escape" attribute to give the VM the freedom to put it on the stack. Of course, since Sun is Sun, we'll never see either feature.
Does anyone know how it guarantees stack allocation? I couldn't find any native code in there so I wonder how it does it. I suppose you could code it in such a way that it's easy for the JVM to infer that certain objects don't "escape" from the stack, but that would be somewhat unreliable. Or are they just calling the zero-cost allocation "stack allocation" to get the attention of people (like me) who get all excited when they hear that term associated with memory-managed languages?:)
Your example of extending Thread versus implementing Runnable is a bad one.
I was using it as an example of where it is possible to use inheritance (and people do) but it is a bad idea. I used that example because you said you weren't familiar with ObjectOutputStream. But thanks for another installment of "Intro to OO for Literature Majors". Again, your examples are at such a high level that they won't help anyone but absolute beginners. You have to look at complex real-world API requirements if you want to try and tackle the more difficult issues.
Your "extending the concept" heuristic is flawed. Subclassing involves inheritance of interface and implementation. Extending an interface involves inheritance of just the interface. In a language with multiple-inheritance, you could make Orange extend both Fruit and FoodContainer. Java just forces you to pick one. The reason you'd probably choose to derive from Fruit is that you'd save more typing by inheriting Fruit's implementation than you would by inheriting FoodContainer's. There's nothing unnatural about having Orange derive from FoodContainer or having Orange simply implement the Fruit interface.
No there is nothing wrong the philosophy. Sometimes Sun strays from their own views thats all.
While you can always get away with dismissing all bad classes as examples of "straying" from the philosophy, I think the API has many examples of excessive inheritance -- enough to suggest that it was part of their original philosophy. In the end, you can't really tell whether it was part of their philosophy or they just got careless in some places, but it doesn't matter. The API does have problems. The fact that there exists an ideal philosophy doesn't help me use an API that doesn't follow it.
Kinda like there must be something wrong with Christianity/Islam if David Koresh/9-11 hijackers did what they did.
I happen to thing that there is something wrong with Christianity/Islam. (I'm not naive enough to try and argue that topic on Slashdot, though).
If there is something wrong with a class (I've never used ObjectOutputStream) then that doesn't mean that there is something wrong with the philosophy.
If the philosophy caused the crappy class, then, by definition, there is something wrong with the philosophy. If the philosophy didn't cause the crappy class, then the API is inconsistent. In Java, it's a little of both.
The original Java API philosophy was "let's make everything a subclass." An example of this would be deriving from java.lang.Thread instead of implementing java.lang.Runnable. At first, most people seemed fine with it but over time it has become "frowned upon."
Java also has a problem with unnecessary layers of separation. An example of this is how Swing and AWT separate layout managers from panels. That's why you have the weakly-typed add methods. Now, please resist the urge to imply that I don't know what inheritance or categorization means or that I should learn some more programming languages. This API is just crappy. They drew the boundaries in the wrong places.
Your "5 kingdoms" metaphor only goes so far. It's a nice example to use when explaining the general concept of subclassing to a beginner but, seriously, any programmer knows this. The difficulty is in figuring out how to categorize and not whether categorization is a good thing.
because every input stream is a subclass of InputStream? You code for InputStream and you can support them all. If you needed the added support of a subclass use that one. I like Java's hierarchy. It reminds me of the ordering of natural sciences starting with "Living Things" (ie java.lang.Object) to the 5 kingdoms etc.
I don't think "because everything else is done that way" is a good enough reason. If you had an ObjectOutputStream, there's no reason to expose the raw write() methods. If you want to do write raw data, use the original OutputStream (the one you passed in to create the ObjectOutputStream).
There are three types of extensions to output streams. An example of the first type is FileOutputStream. It creates an output stream interface to files. An example of the second type is BufferedOutputStream, which can be used as an adapter on top of any existing output stream to change its behavior. An example of the third type is ObjectOutputStream, which uses an output stream to do something else. It shouldn't be used to write raw data and therefore shouldn't look like something that is.
I agree. The interface should have been sub-classed and then if you were going to implement the "optional" methods you'd implement the subclass. This angers me too... however I feel you'll hate my solution.
Again, you're assuming that anybody who doesn't like the Java API is afraid of fine-grained layering. I would be fine with a more complete set of interfaces. Unfortunately, the Java language doesn't have good syntax for defining and combining orthogonal traits (i.e. random-accessible, enumerable, read-only, etc.) and so I imagine people would complain about the added complexity.
I must say that is mitigated by the fact the Java has hands down the best API documentation for any platform. Really what more could you ask for.
I agree that good documentation helps and that Java libraries are well-documented. However, that's still not a reason to downplay complaints against bad APIs.
You also shouldn't assume that people who don't like some Java API's are just OO-deficient C people who don't see the "elegance" of layering. You have to layer in the right places.
The original API designers seemed to be way too inheritance-happy. There's a lot of tight coupling. For example, why does ObjectInputStream inherit from InputStream?
The 1.2 collections API, though it was pretty nice in general, had interfaces with "optional methods" (i.e. you could choose whether to implement them or just throw an exception). They just threw static typing out the window.
Why in the world would you want to throw away one of Java's major advantages just to save yourself the minor inconvenience of having to learn something new?
The guy was complaining about Java's not-so-great I/O API. That doesn't mean he doesn't like automatic memory management. Java's particular I/O API is not a prerequisite for automatic memory management.
I also don't think he's complaining about "the inconvenience of learning something new." A well-designed API doesn't require much storage space in your brain. A poorly designed API requires more brain space because you can generalize/infer fewer things and are forced to remember all the inconsistencies and special cases. The Java API has a lot of these and that's probably why he has to keep going back to the API docs.
Ok, now it seems like you might just be screwing around and I probably shouldn't reply, but I can't help myself...
A language which runs on top of parrot is generating parrot byte-code. If it's not generating parrot byte-code, it's not "native", and therefore, not running on parrot.
Ok, back to the original example. Let's say you're writing a LanguageX to Parrot compiler. Assume that Parrot doesn't have specific bytecodes for enum support but that the compiler can encode enum types using existing Parrot bytecodes. This compiler will produce only standard Parrot bytecode. Parrot will not need to be modified at all to run the compiled programs.
That was the situation the original poster was talking about. And since there are probably many ways to encode enum types using pure Parrot bytecode, the compiler for LanguageZ might use a different technique. Both compilers have enum support, both compilers produce only pure Parrot bytecode, but programs written in the two languages may not be able to pass enum types back and forth.
Nobody is saying that this is Parrot's fault. They're just saying that you need more than interoperability issues don't end with the creation of a VM. They'll need to define an "official" encoding for every the various categories of data types (classes, enums, function pointers, etc.).
Parrot is a instruction set and a runtime environment. I think that running entirely on that instruction set qualifies as "running on Parrot".
For example, most people would agree that Java runs on the JVM. However, the JVM instruction set doesn't have an if-then-else bytecode instruction. It only has asm-style branch/goto instructions. The Java compiler has to translate 'if-then-else' into bytecode. Because of that, would you consider Java to not run on the JVM?
Why do you use the term "[language] runs Parrot" instead of "[language] runs on Parrot"?
I may have misunderstood your post, but this is what you said to the parent poster:
What's you're point? You're point is that some people will use Parrot and others will use a different VM? I think we all, already understood this.
The parent poster did not say that others will use a different VM. They will run on Parrot. They will just have to interoperate at the lowest common denominator.
If you have a language, which can not "natively" run in the parrot VM, then you're not running the parrot VM.
What does that even mean? Even if you have come up with a new way of representing enums, you'll still only be using the standard Parrot VM instructions. If you have a program that compiles exclusively to Parrot bytecode and runs entirely within the Parrot VM with no JNI-type extensions, wouldn't you say that it runs on Parrot?
BTW, your "I'm rubber, you're glue" comeback brings back memories...
I think Debian creates home directories that are world readable. The default umask is 022, which is "rw-r--r--". Applications tend to set the permissions correctly on directories and files they create (OpenSSH, mail clients, GNOME).
but some scripting languages will probably define additional features (macros, MI, continuations etc.) that have no "native" representation in Parrot
So? That just means that they are not using Parrot. Big deal. What's you're point? You're point is that some people will use Parrot and others will use a different VM? I think we all, already understood this.
So much anger...so clueless...
The parent post was talking about a situation where other languages do run on Parrot but there's still an interoperability barrier. Here's the situation:
You created a programming language and you wrote a compiler that targets Parrot.
You want your language to have enums.
The Parrot VM doesn't have a native concept of enums (this may or may not be true).
You see that there are many techniques to simulate enums using existing Parrot constructs.
You choose one of those techniques.
Now you have enums and you're running on Parrot. But you might not be able to pass your enum values to code written in another Parrot language. Why not? Because the compiler-writer for the other language may have used a different (though equally valid) technique to encode enums.
That's no problem, we'll just define a standard for all enum types so that all compiler-writers can use the same encoding technique. Let's do that for all the language constructs we can think of! The only problem is that new languages introduce new/better concepts and we can't define all those in advance. The JVM and CLR are good examples of this problem. They're both lacking functionality that would be required to support better type systems (my biggest gripe is the lack of discriminated unions). All interoperability happens at the level of the crappiest type system.
The Python VM is a directy bytecode interpreter. It doesn't do JIT. Trying to retrofit JIT on a interpreter doesn't save you much work.
Re:I code C# for a living
on
Java 1.5 vs C#
·
· Score: 1
Whoops, my mistake. I changed it to:
class Test { . public static void Main() { . . A a = new A(); . . a.b.c = "Moose"; . . System.Console.WriteLine(a.b.c); . } } class A { . private B _b = new B(); . public B b { get { return _b; } set { _b = value; } } } class B { . private string _c = "Goose"; . public string c { get { return _c; } set { _c = value; } } }
It still works. I tested with both Mono and Microsoft's 1.1 SDK.
Re:I code C# for a living
on
Java 1.5 vs C#
·
· Score: 1
There is a relationship between
map and the thing that you insert as a parameter.
What is that relationship? Can you come up with a good name for it? The map function is extremely generic and so there's no name you can give it that will provide any more useful information than its function signature.
Regarding maintainability... Traditionally the most common maintainability issues are caused when lazy programmers forget to document things or give variables uselessly short variable names. This is why many people I've met (and you seem to be one of them) use the heuristic that verbosity increases maintainability. That heuristic will work fine a lot of the time, but it doesn't take into account that redundancy reduces maintainability. In this case, the extra interface name is redundant and will not improve maintainability.
Re:I code C# for a living
on
Java 1.5 vs C#
·
· Score: 1
The other thing with properties is that they look like fields, but don't work that way, for example, if B and C are implemented as properties, then this will not compile under C#:
A.B.C = someVal;
Could you elaborate? I tried this and it worked for me:
class Test { . public static void Main() { . . A a = new A(); . . System.Console.WriteLine(a.b.c); . } } class A { . private B _b = new B(); . public B b { get { return _b; } } } class B { . private string _c = "Goose"; . public string c { get { return _c; } } }
Were you trying something weirder than that? I know that properties aren't implemented perfectly (they don't work as "ref" or "out" parameters and they're different from fields at the bytecode level), but I'd be surprised if something a simple as this didn't work. (I tested with Mono, not with the Microsoft stuff).
The good thing about OO is that the methods on classes represent the communication contract between entities. This is an important API and should be as explicit as possible, not virtually rendered anonymous as in C#
Even with the Java method, you still wont know everything there is to know about the ActionListener . All you know is that it might be called by some source that emits ActionEvents. Who cares? You still have no idea who will call it. The bit of information about when/why it will be called is much more important than the simple fact that it is an ActionListener. The extra information is usually provided by the programmer in comments, so you're not really any much better off.
With C#, you can provide comments, but you can also set the method name to reflect what it really does, possibly eliminating the need to read the comments. (In Java, you can emulate this by providing this information in the parameter name.)
public void cancelButtonPressed(int howHard, int howLong);
public void actionPeformed(ActionEvent cancelButtonPressEvent);
Also, for each event source, you'll need to create a new inner class (another opportunity to provide a meaningful name!). This is tedious and so the most common "solution" is to send all the events into one class and explicitly demultiplex them (which, obviously, is stupid).
Re:I code C# for a living
on
Java 1.5 vs C#
·
· Score: 1
That's hardly a million miles away from:
Interface realFunc { public double calculate(double in); }
You're leaving out the code you need to actually use the interface you created. This is how you'd do it if you had function pointers:
Now, this could have been shorter if every function in java.lang.Math were actually a separate object that implemented the appropriate interface, but doing so would be stupid. You'd have an entire class of interfaces with completely redundant names. RealFunc is a stupid name because it gives you no new information; all you need to know is in the function signature. By giving it a name, you're essentially wasting time performing manual C++-style name mangling (for no reason at all).
Re:Tuples? I Haven't Heard That in Years...
on
Java 1.5 vs C#
·
· Score: 1
In programming languages, "tuple" usually means a record with anonymous fields that can be constructed on the fly. So Perl does have support for that (though things are a little different in dynamically typed languages because they don't even really have records in the first place).
In C, when you call functions, you are allowed to pass in tuples. That's why you can write:
// Declaration void CopyChars(StringBuffer src, StringBuffer dst, int length);
The CLR VM knows about generics so it can safely get rid of the casts. The Sun idiots chose not to modify the JVM bytecode to accomodate generics, so the casts need to be there. You don't see the casts because "javac" inserts them for you, but they're still in there, doing what they do best: kill performance.
While the 50%-70% improvement is definitely not typical, if you do some intense algorithms on collection classes, then you'll probably see that kind of speed up. Just don't expect that kind of speedup for a real-world application.
Re:I code C# for a living
on
Java 1.5 vs C#
·
· Score: 1
I am aware of this behavior, but it's not usually what the programmer requires. I'm betting that 99% of the time 'out' is used, the programmer doesn't rely on this weird behavior. All he wants is multiple return values. The other 1% of the time probably consists of things you shouldn't be doing anyway:)
The advantage of tuples is that they make things more general. C, Java and C# do have tuples. It's just that they're only allowed as arguments to functions. This limitation makes it really difficult to do some things cleanly (for example, the CLR "Delegate" class is a huge back-end hack). Also, you can't pass properties as 'out' parameters because they need to be set through method invocations. Crappy tuple support is really holding back C# and I'm surprised they actually chose 'out' parameters over proper tuple support. Tuple-friendly languages have been around for a long time and so it's not even like they'd be breaking new ground.
That's a neat way of swapping around pluggable modules. However, there is still the problem of forcing the client programmer to be aware of the specific implementation dependencies in cases where things weren't designed to be modularly swapped out.
Not that any of that is relevant because Rob Pike's note on include files doesn't mention any of that stuff. He says that the problem is repeated inclusion of files. He also explicitly mentions that he is aware of include guards and his only stated objection is that they make the compilation take longer (which is not even neccessarily true; GCC uses a clever trick to detect the include guard pattern and avoid redundantly tokenizing files).
The C include system is fundamentally flawed and so even include guards have problems. But Rob Pike seemed to dismiss the technique outright, which is why he came off as a little bit of a weirdo.
Re:I code C# for a living
on
Java 1.5 vs C#
·
· Score: 1
"Out" parameters are used to return more than one value. But "out" parameters are the wrong way to accomplish that. They are a holdover from the old C technique for faking multiple return values.
Slashdot Mirror
I can guarantee that they have.
Graph algorithms are good for testing out a language's data structures. Dijkstra's single-source shortest path function is a good one to start with.
The problem is to create a function that takes NO input and produces 27.
There's some hand-waving about making the program general-purpose, but it's too imprecise to be of any use. You need inputs.
Explicit annotation would help with virtual methods. Since classes can be dynamically loaded, the JIT can never say that "parameter X of virtual method M never escapes the stack." You can improve performance with optimistic approximations, but you're going to have to undo a lot of work if one "bad" method override gets loaded. The problem could be mitigated by good heuristics. I believe that they already do some "unvirtualization" of method calls, which would also help.
I suppose it could be a bad thing to allow "no-escape" annotations on virtual method parameters -- the performance benefit may not be worth the added difficulty -- but I can think of one real-world example where they'd help: java.awt.Component's setSize(...) method. Then again, maybe we just need to make more things immutable.
The object pooling is neat, but it's still too inconvenient for normal use. It's not too inconvenient for people who need the performance, though. It's also not too inconvenient for those who think they need the performance and are already doing some sort of custom object pooling. I wont be using it though.
We need language-level support for more efficient memory use. We need to be able to more precisely declare how we're going to use an object and let the VM handle the optimizations automatically. The FAQ suggests that the 'new' allocator should be overridable but even that is at too low a level. I want to be able to declare parameters with the "no-escape" attribute to give the VM the freedom to put it on the stack. Of course, since Sun is Sun, we'll never see either feature.
Does anyone know how it guarantees stack allocation? I couldn't find any native code in there so I wonder how it does it. I suppose you could code it in such a way that it's easy for the JVM to infer that certain objects don't "escape" from the stack, but that would be somewhat unreliable. Or are they just calling the zero-cost allocation "stack allocation" to get the attention of people (like me) who get all excited when they hear that term associated with memory-managed languages? :)
I was using it as an example of where it is possible to use inheritance (and people do) but it is a bad idea. I used that example because you said you weren't familiar with ObjectOutputStream. But thanks for another installment of "Intro to OO for Literature Majors". Again, your examples are at such a high level that they won't help anyone but absolute beginners. You have to look at complex real-world API requirements if you want to try and tackle the more difficult issues.
Your "extending the concept" heuristic is flawed. Subclassing involves inheritance of interface and implementation. Extending an interface involves inheritance of just the interface. In a language with multiple-inheritance, you could make Orange extend both Fruit and FoodContainer. Java just forces you to pick one. The reason you'd probably choose to derive from Fruit is that you'd save more typing by inheriting Fruit's implementation than you would by inheriting FoodContainer's. There's nothing unnatural about having Orange derive from FoodContainer or having Orange simply implement the Fruit interface.
While you can always get away with dismissing all bad classes as examples of "straying" from the philosophy, I think the API has many examples of excessive inheritance -- enough to suggest that it was part of their original philosophy. In the end, you can't really tell whether it was part of their philosophy or they just got careless in some places, but it doesn't matter. The API does have problems. The fact that there exists an ideal philosophy doesn't help me use an API that doesn't follow it.
I happen to thing that there is something wrong with Christianity/Islam. (I'm not naive enough to try and argue that topic on Slashdot, though).
If the philosophy caused the crappy class, then, by definition, there is something wrong with the philosophy. If the philosophy didn't cause the crappy class, then the API is inconsistent. In Java, it's a little of both.
The original Java API philosophy was "let's make everything a subclass." An example of this would be deriving from java.lang.Thread instead of implementing java.lang.Runnable. At first, most people seemed fine with it but over time it has become "frowned upon."
Java also has a problem with unnecessary layers of separation. An example of this is how Swing and AWT separate layout managers from panels. That's why you have the weakly-typed add methods. Now, please resist the urge to imply that I don't know what inheritance or categorization means or that I should learn some more programming languages. This API is just crappy. They drew the boundaries in the wrong places.
Your "5 kingdoms" metaphor only goes so far. It's a nice example to use when explaining the general concept of subclassing to a beginner but, seriously, any programmer knows this. The difficulty is in figuring out how to categorize and not whether categorization is a good thing.
I don't think "because everything else is done that way" is a good enough reason. If you had an ObjectOutputStream, there's no reason to expose the raw write() methods. If you want to do write raw data, use the original OutputStream (the one you passed in to create the ObjectOutputStream).
There are three types of extensions to output streams. An example of the first type is FileOutputStream. It creates an output stream interface to files. An example of the second type is BufferedOutputStream, which can be used as an adapter on top of any existing output stream to change its behavior. An example of the third type is ObjectOutputStream, which uses an output stream to do something else. It shouldn't be used to write raw data and therefore shouldn't look like something that is.
Again, you're assuming that anybody who doesn't like the Java API is afraid of fine-grained layering. I would be fine with a more complete set of interfaces. Unfortunately, the Java language doesn't have good syntax for defining and combining orthogonal traits (i.e. random-accessible, enumerable, read-only, etc.) and so I imagine people would complain about the added complexity.
I agree that good documentation helps and that Java libraries are well-documented. However, that's still not a reason to downplay complaints against bad APIs.
You also shouldn't assume that people who don't like some Java API's are just OO-deficient C people who don't see the "elegance" of layering. You have to layer in the right places.
The guy was complaining about Java's not-so-great I/O API. That doesn't mean he doesn't like automatic memory management. Java's particular I/O API is not a prerequisite for automatic memory management.
I also don't think he's complaining about "the inconvenience of learning something new." A well-designed API doesn't require much storage space in your brain. A poorly designed API requires more brain space because you can generalize/infer fewer things and are forced to remember all the inconsistencies and special cases. The Java API has a lot of these and that's probably why he has to keep going back to the API docs.
Ok, now it seems like you might just be screwing around and I probably shouldn't reply, but I can't help myself...
Ok, back to the original example. Let's say you're writing a LanguageX to Parrot compiler. Assume that Parrot doesn't have specific bytecodes for enum support but that the compiler can encode enum types using existing Parrot bytecodes. This compiler will produce only standard Parrot bytecode. Parrot will not need to be modified at all to run the compiled programs.
That was the situation the original poster was talking about. And since there are probably many ways to encode enum types using pure Parrot bytecode, the compiler for LanguageZ might use a different technique. Both compilers have enum support, both compilers produce only pure Parrot bytecode, but programs written in the two languages may not be able to pass enum types back and forth.
Nobody is saying that this is Parrot's fault. They're just saying that you need more than interoperability issues don't end with the creation of a VM. They'll need to define an "official" encoding for every the various categories of data types (classes, enums, function pointers, etc.).
Parrot is a instruction set and a runtime environment. I think that running entirely on that instruction set qualifies as "running on Parrot".
For example, most people would agree that Java runs on the JVM. However, the JVM instruction set doesn't have an if-then-else bytecode instruction. It only has asm-style branch/goto instructions. The Java compiler has to translate 'if-then-else' into bytecode. Because of that, would you consider Java to not run on the JVM?
Why do you use the term "[language] runs Parrot" instead of "[language] runs on Parrot"?
I may have misunderstood your post, but this is what you said to the parent poster:
The parent poster did not say that others will use a different VM. They will run on Parrot. They will just have to interoperate at the lowest common denominator.
What does that even mean? Even if you have come up with a new way of representing enums, you'll still only be using the standard Parrot VM instructions. If you have a program that compiles exclusively to Parrot bytecode and runs entirely within the Parrot VM with no JNI-type extensions, wouldn't you say that it runs on Parrot?
BTW, your "I'm rubber, you're glue" comeback brings back memories...
I think Debian creates home directories that are world readable. The default umask is 022, which is "rw-r--r--". Applications tend to set the permissions correctly on directories and files they create (OpenSSH, mail clients, GNOME).
So much anger...so clueless...
The parent post was talking about a situation where other languages do run on Parrot but there's still an interoperability barrier. Here's the situation:
Now you have enums and you're running on Parrot. But you might not be able to pass your enum values to code written in another Parrot language. Why not? Because the compiler-writer for the other language may have used a different (though equally valid) technique to encode enums.
That's no problem, we'll just define a standard for all enum types so that all compiler-writers can use the same encoding technique. Let's do that for all the language constructs we can think of! The only problem is that new languages introduce new/better concepts and we can't define all those in advance. The JVM and CLR are good examples of this problem. They're both lacking functionality that would be required to support better type systems (my biggest gripe is the lack of discriminated unions). All interoperability happens at the level of the crappiest type system.
The Python VM is a directy bytecode interpreter. It doesn't do JIT. Trying to retrofit JIT on a interpreter doesn't save you much work.
Whoops, my mistake. I changed it to:
It still works. I tested with both Mono and Microsoft's 1.1 SDK.
What is that relationship? Can you come up with a good name for it? The map function is extremely generic and so there's no name you can give it that will provide any more useful information than its function signature.
Regarding maintainability... Traditionally the most common maintainability issues are caused when lazy programmers forget to document things or give variables uselessly short variable names. This is why many people I've met (and you seem to be one of them) use the heuristic that verbosity increases maintainability. That heuristic will work fine a lot of the time, but it doesn't take into account that redundancy reduces maintainability. In this case, the extra interface name is redundant and will not improve maintainability.
Could you elaborate? I tried this and it worked for me:
Were you trying something weirder than that? I know that properties aren't implemented perfectly (they don't work as "ref" or "out" parameters and they're different from fields at the bytecode level), but I'd be surprised if something a simple as this didn't work. (I tested with Mono, not with the Microsoft stuff).Even with the Java method, you still wont know everything there is to know about the ActionListener . All you know is that it might be called by some source that emits ActionEvents. Who cares? You still have no idea who will call it. The bit of information about when/why it will be called is much more important than the simple fact that it is an ActionListener. The extra information is usually provided by the programmer in comments, so you're not really any much better off.
With C#, you can provide comments, but you can also set the method name to reflect what it really does, possibly eliminating the need to read the comments. (In Java, you can emulate this by providing this information in the parameter name.)
Also, for each event source, you'll need to create a new inner class (another opportunity to provide a meaningful name!). This is tedious and so the most common "solution" is to send all the events into one class and explicitly demultiplex them (which, obviously, is stupid).
You're leaving out the code you need to actually use the interface you created. This is how you'd do it if you had function pointers:
This is how you'd do it if you didn't:
Now, this could have been shorter if every function in java.lang.Math were actually a separate object that implemented the appropriate interface, but doing so would be stupid. You'd have an entire class of interfaces with completely redundant names. RealFunc is a stupid name because it gives you no new information; all you need to know is in the function signature. By giving it a name, you're essentially wasting time performing manual C++-style name mangling (for no reason at all).
In programming languages, "tuple" usually means a record with anonymous fields that can be constructed on the fly. So Perl does have support for that (though things are a little different in dynamically typed languages because they don't even really have records in the first place).
In C, when you call functions, you are allowed to pass in tuples. That's why you can write:
Instead of:
Isn't that fun? Currently, this is what you have to for multiple return values.
The CLR VM knows about generics so it can safely get rid of the casts. The Sun idiots chose not to modify the JVM bytecode to accomodate generics, so the casts need to be there. You don't see the casts because "javac" inserts them for you, but they're still in there, doing what they do best: kill performance.
While the 50%-70% improvement is definitely not typical, if you do some intense algorithms on collection classes, then you'll probably see that kind of speed up. Just don't expect that kind of speedup for a real-world application.
I am aware of this behavior, but it's not usually what the programmer requires. I'm betting that 99% of the time 'out' is used, the programmer doesn't rely on this weird behavior. All he wants is multiple return values. The other 1% of the time probably consists of things you shouldn't be doing anyway :)
The advantage of tuples is that they make things more general. C, Java and C# do have tuples. It's just that they're only allowed as arguments to functions. This limitation makes it really difficult to do some things cleanly (for example, the CLR "Delegate" class is a huge back-end hack). Also, you can't pass properties as 'out' parameters because they need to be set through method invocations. Crappy tuple support is really holding back C# and I'm surprised they actually chose 'out' parameters over proper tuple support. Tuple-friendly languages have been around for a long time and so it's not even like they'd be breaking new ground.
That's a neat way of swapping around pluggable modules. However, there is still the problem of forcing the client programmer to be aware of the specific implementation dependencies in cases where things weren't designed to be modularly swapped out.
Not that any of that is relevant because Rob Pike's note on include files doesn't mention any of that stuff. He says that the problem is repeated inclusion of files. He also explicitly mentions that he is aware of include guards and his only stated objection is that they make the compilation take longer (which is not even neccessarily true; GCC uses a clever trick to detect the include guard pattern and avoid redundantly tokenizing files).
The C include system is fundamentally flawed and so even include guards have problems. But Rob Pike seemed to dismiss the technique outright, which is why he came off as a little bit of a weirdo.
"Out" parameters are used to return more than one value. But "out" parameters are the wrong way to accomplish that. They are a holdover from the old C technique for faking multiple return values.