While performance is really a result of implementation rather than languages, there are, in practice, faster and slower languages.
C is usually the fastest in comparisons. C compilers are relatively mature, and C programs require minimal run-time support. A C program will normally be compiled to something that can be loaded and executed, with just a little preparation on the part of the computer. (There have been C interpreters, and they were slow like you'd expect.)
Fortran is not usually in those computations, but is similar in most respects. Fortran was inherently faster in large-scale floating-point computations than the C of the original Standard, since the Fortran compiler could assume, say, that the three matrices passed to a multiplication program were disjoint, and could optimize on that basis. C compilers couldn't assume that.
Java programs are normally compiled to an artificial machine language, and that is normally compiled on the fly (just-in-time compiling). That could theoretically be faster than C-style compilation (it could make better guesses about the flow of execution, and it could tailor the compilation to the exact system in use), but in practice isn't. Java also requires more run-time support, such as a garbage collector, and the JIT compiler and runtime have to load and get going. That results in increased startup time, which can be noticeable.
Python programs are normally compiled to an artificial machine language and then interpreted, which is slower. It is possible to store the compiled files (".pyc"), but frequently only the source is stored, so to execute it is necessary to compile first and then interpret, which is slow. Also, Python has dynamic typing, which means the compiler doesn't know everything's type up front, and therefore Python functions have to be able to take different data types at runtime, which is inefficient.
There's always room for surprises. On one celebrated occasion, a CMU Common Lisp program out-number-crunched a Fortran program. Common Lisp requires garbage collection, which apparently wasn't an issue in that application, and normally is dynamically typed, but it's possible to declare all types statically. The Fortran compiler had a small inefficiency the CMU Common Lisp compiler didn't, and was duly improved afterwards.
Hmm... That definition looks very similar to some haskell sample I've seen long time ago.
{-# LANGUAGE ExistentialQuantification #-}
data X = forall a . X { value :: a, viewValue :: a -> String }
instance Show X where show (X { value = x, viewValue = f}) = f x
sample :: [X]
sample = [X 3 show, X "abc" show, X 3.14 show]
When constructor X
is applied ∀ actually becomes ∃. Note that when you take out value
you don't know the type and have empty set of operation over it. But since viewValue
is kinda coherent with value
it can be applied to it.
I guess the main difference of Java interface
you proposed is the fact that you have to know intermediate type for passing result of op₁
to op₂
. I.e. proper system for existential type should select the right type which is guaranteed to exist by condition. I.e. you should be able to write function with type: ∀X. X→(X→boolean)→T
. In prev sample such function is X
constructor used in X 3 show
(show
is function which takes argument of any type that implements Show
and returns String
)
Updated: I just re-read your question and I think I've got proper construction for Java:
interface T {
boolean op₂();
}
...
T x = new T() {
private final int op₁ = ...;
public boolean op₂() { return ((op₁ % 2) == 0); }
};
T y = new T() {
private final char op₁ = ...;
public boolean op₂() { return ('0' <= op₁ && op₁ <= '9'); }
};
if (x.op₂() && y.op₂()) ...
You are right about mentioning this
- it's actually your op₁.
So I guess I understood now that classical OOP languages (Java, C#, C++ etc) always implement existential type with single value this
and a functions over it called "methods" which implicitly called with that value :)
P.S. Sorry, I'm not very familiar with Java, but I hope you've got the idea.
Best Answer
Java is object-compatible. You compile it on one patform and the resultant class files can run on any JVM.
C is source-portable. You can take your C source code and compile it on any ISO C compiler, provided you follow the rules - that means no using undefined or implementation defined behaviour or any non-standard features.