[Prev][Next][Index][Thread]

Fw: Beyond Java?

Hi,

Maxim Kizub has started an interesting discussion with Fun'O about my
"Beyond Java" article. I think it deserves a wider audience. Maxim has
agreed to a repost of the initial messages on our mailing list. Here is the
first message.

__Jason

----- Original Message -----
> >Date: Sun, 4 Mar 2001 20:22:35 +0100
> >From: Maxim Kizub <M.Kizub@post.skynet.lt>
> >Subject: Beyond Java?
> >
> >-----BEGIN PGP SIGNED MESSAGE-----
> >Hash: SHA1
> >
> >Hello webmaster,
> >
> >   You have not provided e-mail address of Dr Jason Trenouth,
> >so, I'm asking you - whould you forward this replay to his
> >article "Beyond Java?", please?
> >(http://www.functionalobjects.com/resources/beyond-java.phtml)
> >
> >=============================
> >Dear Dr Jason Trenouth
> >
> >I read your article "Beyond Java?" and I disagree
> >with you. Let me explain:
> >
> >1) Single Implementation Inheritance
> >
> >The single inheritance is not a bad choice.
> >It's, IMHO, a very wise choice - because
> >java creators choosed to use virtual table
> >method dispatching, and those 'solutions'
> >for multiple inheritance that we see in C++
> >only shows that multiple inheritance is a BAD
> >thing.
> >Anyway, I agree that multiple inheritance is
> >sometimes a convinient technique, but it (usually)
> >may be solved by others approaches. For example,
> >allowing methods of interface be 'default'
> >implementation of functions for classes that
> >implements this interface, but do not define
> >those functions. Another example - delegation.
> >And note - both of these techniques do not require
> >method dispatching by messages - and, thus, are
> >about as fast as virtual methods calls.
> >
> >2) Single Argument Method Dispatch
> >
> >All your arguments are correct, but you do not
> >mentioned one issue - single argument dispatching
> >(that can be done with virtual table) are FAST,
> >while multiple-argument dispatching is SLOW.
> >VERY SLOW.
> >And all your arguments costs nothing, if developer
> >needs fast execution - if in normal situation
> >only a few methods in the whole program really
> >needs multiple-argument dispatching - your solution
> >to dispatch _all_ calls in this way is unacceptable
> >in most situation.
> >
> >3) Primitive Types Distinct From Objects
> >
> >The same as above. Primitive types are FAST and
> >requires no additional memory allocation.
> >
> >4) Casting Required
> >
> >I agree, it's a problem. Even if java will have
> >parametriezed types in future - I do not belive
> >they will solve the problem.
> >
> >5) No Extensible Syntax
> >
> >Again, I agree with you.
> >
> >6) Poor Iteration/Collection Integration
> >
> >This is the problem of initial language design.
> >End situation is even wirse - Iterators are
> >disaster in multithreaded environment.
> >
> >
> >
> >So, the main problem with your article - is that
> >you some facts that were the reason of why java
> >developers choosed single inheritance and
> >virtual-table dispatching.
> >
> >Of cause, you know 20/80 rule (20% of peoples
> >drink 80% of beer ;-) ). The same is for programs -
> >20% of code (or less) are executed 80% of time
> >(or more). So, really good language is the language
> >that do not enforce any technique - single or
> >multiple inheritance, single or multi-argument
> >dispatching and so on.
> >
> >Those 80% of code that aren't critical from speed
> >point of view - are critical from amout of errors
> >and design. They needs to be written in convinient
> >(for programmers) way - to minimize amount of errors
> >and the cost of development. The rest 20% needs to
> >be written to be fast by any price.
> >
> >The problem is that low-level fast part of a program
> >must coexists with high-level part of the program.
> >There are two approaches - have strict design of
> >data and methods calls (like CLR in MS .NET), which
> >allows some parts of programs to be written in
> >C/C++, and others - in C#, basic and others, that
> >supports CLR.
> >Another solution - is to have a language that have
> >both high-level and low-level ways of programming...
> >Like macro-assemblers... Unfortunatly, assemblers
> >are too low-level now, and usage of C (as low-level
> >language) is not possible for most of projects
> >(and especially - as low-level part of languages
> >that require dynamic binding and mudules loading,
> >like java and amny others - that use own VM).
> >
> >- From this point of view MS' C# is not step aside -
> >it's a step in right direction (take those
> >structures, added into C#, for example), but it's,
> >actually, only a half of step. The real step
> >in right direction - is to have CLR that supports
> >a rich set of data types (both primitive and objects,
> >wrappers for primitive types, structures, pointers,
> >method pointers and closures and so on), and rich set
> >of method calls (direct calls, virtual-table calls,
> >dispatching by message sending and by multiple
> >arguments, calls to function pointers and closires,
> >tail-recursive calls, and re-entrant calls needed
> >for efficient implementation of logical programming
> >languages and so on).
> >
> >On top of this CLR (or VM) may be constructed new
> >languages or used currently existing languages, probably
> >with some extensions of accessing data and calling
> >others languages. I.e., a Dylan may be easily implemented
> >on top of this VM, because it will support all
> >concepts of Dylan, but Dylan itself may be extended
> >to support calls to "low-level" languages that
> >use direct calls or virtual-table dispatching and so on,
> >and Dylan may be extended to automatically
> >wrap/unwrap data sent to those functions or
> >access low-level primitive fields of objects
> >of others languages.
> >
> >Constructed in this way a program may have even more
> >then two layers - it may have a few functions written
> >in assembler (let's say - an abstract assembler, that
> >may be translated and optimized into real hardware
> >codes by JIT compiler), plus 20% of code written in
> >low-level C-like language, plus 60% of code written
> >in more advanced language like Dylan, plus 20%
> >of code written in special script language, that
> >will directly reflect the main task of the
> >program, thus allowing extremly fast writing of
> >program prototype and will allow easy-modified
> >functionality or look-and-feel of the program.
> >
> >
> >=============================
> >
> >- --
> >Best regards,
> >  Maxim                          mailto:M.Kizub@post.skynet.lt
> >
> >-----BEGIN PGP SIGNATURE-----
> >Version: PGP 6.5i
> >
> >iQA/AwUBOqKH7Ow5enpENJF+EQJf/QCgkPVD45dXMoBpFIA+pDxXHtEbBO0AoN+h
> >AZSu2//5g8ZmS8D8DL65sWHe
> >=M9gu
> >-----END PGP SIGNATURE-----
>
>